Application No. 10/652,327 

Reply to Office Action of June 5, 2008 

REMARKS / ARGUMENTS 

Claims 1-31 are pending in the instant application. Claims 21, 22 and 29- 
31 have been amended to further clarify the language used in the claims and to 
further prosecution of the application. The Applicant submits that the claims 1- 
31 define patentable subject matter in view of the following remarks and 
arguments. 

Claims 29-31 are objected to because of the preambles are allegedly 
indistinguishable from the bodies of the claims, and because of a minor 
grammatical error. The Applicant respectfully traverses these objections, but 
nevertheless has amended claims 29-31 and submits that the preambles are 
distinguishable from the bodies of the claims. The grammatical error in claim 29 
has also been corrected. The Applicant respectively requests that the objection 
to claims 29-31 be withdrawn. 

The Examiner objected claims 21 and 22 for lack of antecedent basis in 
referencing to "(c)" in the dependent claim. The Applicant has amended claims 
21 and 22 to replace "(c)" with the relevant limitation from independent claim 18. 
The Applicant respectively requests that the objection to claims 21-22 be 
withdrawn. 

Claims 29-31 are rejected under 35 U.S.C. 101 for being allegedly 
directed to non-statutory subject matter. Specifically, the Examiner states that "A 
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unified driver per se is a software element and is non-statutory matter...." 
Applicant respectfully traverses this rejection but nevertheless has amended the 
preambles of claim 29-31 as mentioned above. The Applicant believes that the 
amended claim language also renders moot the present rejection under 35 
U.S.C. 101. The Applicant respectfully requests that the rejection to claims 29- 
31 under 35 U.S.C. 101 be withdrawn. 

Claims 1-4, 15-20 and 23 are rejected under 35 USC 102(e) as 
anticipated by Boucher et al. (US Patent. No. 6,226,680, hereinafter "Boucher"). 

Claims 10 and 11 are rejected under 35 USC 103(a) as being 
unpatentable over Boucher, as applied to claim 1 above, and further in view of 
Kistler et al. (US Publication No. 2002/0198934, hereinafter "Kistler"). 

Claims 12-14 are rejected under 35 USC 103(a) as being unpatentable 
over Boucher, as applied to claim 1 above, and further in view of Microsoft 
(Winsock Direct and Protocol Offload on SANs, 03/03/2001, hereinafter 
"Microsoft"). 

Claim 21 is rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 18 above, and further in view of Official Notice, 
hereinafter "ON"). 
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Claim 22 is rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 18 above, and further in view of Yang et al. (US 
Publication No. 2002/0041566, hereinafter "Yang"). 

Claims 5-8 and 24-28 are rejected under 35 USC 103(a) as being 
unpatentable over Boucher, as applied to claim 1 above, and further in view of 
Hayes et al (US Publication No. 2003/0046330, hereinafter "Hayes"). 

Claim 29-31 are rejected under 35 USC 103(a) as being unpatentable 
over Boucher, and further in view of Callaghan (NFS over RDMA, hereinafter 
"Callaghan"). 

I. RESPONSE TO EXAMINER'S ARGUMENTS 

The Examiner, in page 2 of the 6/5/08 Office Action, disagrees with the 
Applicant's argument that Boucher does not teach "a processor operable to 
process a plurality of different types of network traffic," as recited by the Applicant 
in claim 1. The Examiner maintains that Boucher's disclosure of protocol 
processing by " fast path or slow path" are different types of network. The 
Examiner relies on Boucher's Fig. 9, col. 6 lines 39-55, alleging that Boucher's 
disclosure that a packet determined to be routed through a "fast path" for TCP/IP 
offload processing by the INIC processor, is first type of network traffic. The 
Examiner also alleges that the packets that are routed to be handled through a 



Page 12 of 34 



Application No. 10/652,327 

Reply to Office Action of June 5, 2008 



regular host protocol stack, i.e. processed through all the network protocol layers, 
is a second network traffic type. In other words, the Examiner seems to allege 
that the network traffic types are identified by the route the packets are 
processed . The Applicant respectfully disagrees with the Examiner's allegation 
that the "fast path" candidate packet constitutes a different traffic type than the 
"slow path" packet. 

Initially, the Applicant points out that in the same citation by the Examiner 
(col. 6 lines 46-51), Boucher discloses "Subsequent network microprocessor 
work with each fast-path candidate determines whether a fast-path connection 
such as a TCP or SPX CCB is already extant for that candidate, or whether that 
candidate may be used to set up a new fast path connection, such as for a 
TTCP/IP transaction". In other words, Boucher discloses that only a subsequent 
fast path candidate packet with an already created CCB will be routed to the fast 
path. Boucher discloses that each new fast path connection requires that an 
initial fast path candidate packet pass through a host protocol stack for slow path 
processing, just as a slow path packet does, so that a CCB could be created for 
the subsequent fast path candidate packets to be subsequently routed through 
the fast path, i.e., bypassing the host protocol stack to the host storage directly. 

For example, Boucher discloses a flow chart in Fig. 3 with related 
description (see Boucher at col. 6, lines 12- col. 7, line 20) that describes that in 
step 59, a fast path candidate packet (i.e. packet header identified as TCP/IP or 
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SPX/IPX) is identified by the CPD. Next, Boucher discloses that in step 53, an 
initial fast path candidate packet's CCB is not matched to the CCB cache, such 
as is done with respect to a new network traffic connection, where a CCB 
message has not been created to be stored in the CCB cache; the fast path 
packet in step 65, is routed to a host stack for slow path processing, just as 
is done with a slow path packet . In step 51 , a CCB for the fast path candidate 
packet is created. In step 67, the created CCB for the fast path candidate packet 
is stored in the CCB cache in the CPD or INIC. The CCB information in the CCB 
cache will be used to match the CCB of the subsequent fast path candidate 
packets for fast path processing . In other words, Boucher discloses that at 
the beginning of a new network traffic connection, the fast path packet and 
the slow path packet are both routed and processed the same way, i.e., via 
the host protocol stack for slow path processing . The Examiner is referred 
to Boucher's Figs. 4A to 4C and related description (Boucher col. 7, line 20 to 
col. 8, line 12) for further detail and description of the initial network traffic 
connection. 

Therefore, even assuming for the sake of argument that the packets' 
network traffic type is identified by the route the packet is processed, Boucher 
discloses that both the fast path candidate packet (the alleged first network traffic 
type packet) and the slow path packet (the alleged second network traffic type 
packet) are processed through the slow path at the start of a new traffic network 
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connection. Therefore, the Applicant maintains that the fast path packet and 
the slow path packet are of the same network traffic type based on the 
common processing route according to the Examiner's assertion . 

Moreover, the Examiner is referred to Boucher in Fig. 4D and related 
description (col. 8, lines 13-30), where Boucher discloses, that after the network 
traffic has been established (i.e., after the CCB has already been created by an 
initial fast path packet and stored in the CCB cache), a subsequent fast path 
packet is routed to be processed through the host protocol stack slow path 
processing route. Boucher discloses that in a situation where a CCB error 
occurs, or if the CPD processor cannot handle the fast path packet, the fast path 
packet will be processed through the slow path host protocol stack until another 
CCB is created to correct the error in the CCB cache. 

Based on the above, Boucher's disclosure of both the initial network traffic 
connection and after the network traffic connection has been established, 
Boucher discloses that the fast path packet can always be processed by the slow 
path route, in addition to the alternate fast path route. In other words, the 
choice of the fast path route for the fast path packet is purely a 
performance choice, and not because the fast path packet is a different 
network traffic type, as asserted by the Examiner. 

Therefore, the Examiner's rationale that packets belonging to different 
network traffic types (i.e., the fast path packet is different than the slow path 
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packet in network traffic type) are processed by different routes (i.e. fast path 
packets only take the fast path route, the slow path packets only take slow path 
route) cannot support an allegation that the fast path packet is of a different 
network traffic type than that of the slow path packet, since Boucher discloses 
that the fast path packets can always take the slow path route, both at the initial 
network connection establishment, and after the network traffic connection is 
established. 

Based on at least the foregoing rationale, the Applicant maintains that 
Boucher's fast path packet and the slow path packet are of the same network 
traffic type. Accordingly, the Applicant maintains that Boucher does not disclose 
or suggest at least "a processor operable to process a plurality of different types 
of network traffic," as recited by the Applicant in claim 1 . 

Furthermore, the Examiner in page 3 of the Office Action argues that 
Boucher discloses two protocols in Fig. 6, namely TCP/IP and SPX/IPX, which 
are identified in the fast path packet headers. The Examiner alleges that TCP/IP 
and SPX/IPX are two different network traffic types, being supported by the 
hardware processor in Boucher's INIC. 

The Applicant respectfully disagrees, and refers the Examiner to Boucher 
at col. 6, lines 12-21, where Boucher discloses that SPX/IPX (Sequential 
Exchange Protocol (SPX) or Netware Core Protocol over Internetwork Packet 
Exchange (IPX)) work in a similar fashion as TCP/IP . Boucher in the 
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Examiner's citation discloses that a connection needs to be established for the 
fast path packets transaction or processing. In other words, Boucher discloses 
that both TCP/IP and SPX/IPX are protocols that initiate packet transaction 
requests based on a connection establishment between a source and a 
destination, since TCP/IP and SPX/IPX are functionally similar network 
protocol types , i.e., fast path packets with headers identified as either TCP/IP or 
SPX/IPX are processed the same way by the CPD or the INIC hardware logic. In 
fact, the Examiner is further referred to Boucher in col. 6 lines 42-43, where 
Boucher clearly teaches that the packets are identified as fast path candidates if 
"the header has header bytes denoting particular protocols, such as TCP/IP or 
SPX/IPX. for example ". In other words, the CPD or INIC would process the 
fast path packets with headers denoting in either TCP/IP or SPX/IPX in the 
same fashion, not differently . Therefore, the Applicant maintains that Boucher 
does not disclose that TCP/IP and SPX/IPX are different network traffic 
types, as alleged by the Examiner. 

Therefore, based on the above rationale, the Applicant maintains that 
Boucher does not anticipate at least the limitation "the processor operable to 
process a plurality of different types of network traffic," as recited by the Applicant 
in claim 1, and thus claim 1 is allowable. Likewise, independent claim 18 is 
similar in many respects to claim 1, and is therefore also submitted to be 
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allowable. The Applicant respectfully requests that the rejection of independent 
claims 1 and 18 under 35 U.S.C. § 102(e) be withdrawn. 

Likewise, claim 24 is not rendered obvious by the combination of Boucher 
and Hayes, since the combination fails to disclose or suggest at least the 
limitation of "handling a plurality of different types of network traffic via a single 
Ethernet connector," as recited in claim 24 by the Applicant. The Applicant 
respectfully requests that the rejection to claim 24 under 35 U.S.C. § 103(a) be 
withdrawn. 

Likewise, claim 29 is not rendered obvious by the combination of Boucher 
and Callaghan, since the combination fails to disclose or suggest at least the 
limitation of "handling a plurality of different types of network traffic via a single 
PCI bridge," as recited in claim 29 by the Applicant. The Applicant respectfully 
requests that the rejection to claim 29 under 35 U.S.C. § 103(a) be withdrawn. 

II. OBJECTION TO CLAIMS 29-31 AND 21 -22 

Claims 29-31 are objected to because of the preambles are allegedly 
indistinguishable from the bodies of the claims, and because of a minor 
grammatical error. The Applicant respectfully traverses these objections, but 
nevertheless has amended claims 29-31 and submits that the preambles are 
distinguishable from the bodies of the claims. The grammatical error in claim 29 
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has also been corrected. The Applicant requests that the objection to claims 29- 
31 be withdrawn. 

The Examiner objected to claims 21 and 22 for lack of antecedent basis in 
referencing to "(c)" in the dependent claim. The Applicant has amended claims 
21 and 22 to replace "(c)" with the relevant limitation from independent claim 18. 
The Applicant requests that the objection to claims 21-22 be withdrawn. 

III. REJECTION TO CLAIMS 29-31 UNDER 35 U.S.C. § 101 

Claims 29-31 are rejected under 35 U.S.C. 101 for being allegedly 
directed to non-statutory subject matter. Specifically, the Examiner states that "A 
unified driver per se is a software element and is non-statutory matter..." 
Applicant respectfully traverses this rejection but nevertheless has amended the 
preambles of claim 29-31 as mentioned above. The Applicant believes that the 
amended claim language also renders moot the present rejection under 35 
U.S.C. 101. The Applicant respectfully requests that the rejection to claims 29- 
31 under 35 U.S.C. 101 be withdrawn. 

IV. REJECTION UNDER 35 U.S.C. § 102(e) 

MPEP 2131 states: 

"[a] claim is anticipated only if each and every 
element as set forth in the claim is found, either 
expressly or inherently described, in a single prior 
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art reference." See MPEP at 2131 (internal citation 
omitted). Furthermore, "[t]he identical invention 
must be shown in as complete detail as is contained 
in the ... claim." See id. (internal citation omitted). 



A. Boucher Does Not Anticipate Claim 1-4, 15-20 and 23 

The Applicant turns to the rejection of claims 1-4, 15-20 and 23 under 35 
U.S.C. § 102(e) as being anticipated by Boucher. Without conceding that 
Boucher qualifies as prior art under 35 U.S.C. 102(e), the Applicant respectfully 
traverses this rejection as follows. 



A(1) Independent Claims 1 and 18 

With regard to the rejection of independent claim 1 under 35 U.S.C. § 
102(e), the Applicant submits that Boucher does not disclose or suggest at least 
the limitation of "a processor coupled to the network connector, the processor 
operable to process a plurality of different types of network traffic ." as recited 
in the Applicant's claim 1 . 

In the Office Action, the Examiner asserts Boucher discloses the following: 

"a processor coupled to the network connector (fig. 13, 
microprocessor 470, col. 16 line 62-col. 17 line 13), the 
processor being operable to process a plurality of different 
types of network traffic (abstract, col. 3 lines 35-67, col. 13 
lines 24-35, the intelligent network interface card INIC's 
processor supports an offload traffic via fast path and regular 
IP traffic via a slow path)" 
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See the Office Action in page 5. The Examiner relies for support citing the 
following: 

"A network processor 230 determines, based on that 
summary and a comparison with any CCBs stored in the 
INIC 200, whether to send a packet along a slow-path 
231 for processing by the host. A large majority of packets 
can avoid such sequential processing and have their data 
portions sent by DMA along a fast-path 237 directly to the 
data destination 222 in the server according to a matching 
CCB." 

See Boucher at col. 13, lines 24-30, and FIG. 9. The Examiner in the response 
to arguments section relies on Boucher's Fig. 9, col. 6 lines 39-55, alleging that 
Boucher's disclosure that a packet determined to be routed through a "fast path" 
for TCP/IP offload processing by the INIC processor, is a first type of network 
traffic, and that the packets that are routed to be handled through a regular host 
protocol stack, i.e. processed through all the network protocol layers, are a 
second network traffic type. In other words, the Examiner seems to allege that 
the network traffic types are identified by the route the packets are 
processed . The Applicant respectfully disagrees with the Examiner's allegation 
that the "fast path" candidate packet constitutes a traffic type different than the 
"slow path" packet, and refers the Examiner to the applicable arguments in 
Section I above. 

Initially, the Applicant points out that in the same citation by the Examiner 
(col. 6 lines 46-51), Boucher discloses "Subsequent network microprocessor 
work with each fast-path candidate determines whether a fast-path connection 
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such as a TCP or SPX CCB is already extant for that candidate, or whether that 
candidate may be used to set up a new fast path connection, such as for a 
TTCP/IP transaction". In other words, Boucher discloses that only a subsequent 
fast path candidate packet with already created CCB will be routed to the fast 
path. Boucher discloses that each new fast path connection requires an initial 
fast path candidate packet to pass through a host protocol stack for slow path 
processing, just as a slow path packet does, so that a CCB could be created for 
the subsequent fast path candidate packets to be subsequently routed through 
the fast path, i.e., bypassing the host protocol stack to the host storage directly. 

For example, Boucher discloses a flow chart in Fig. 3 with related 
description (see Boucher at col. 6, lines 12- col. 7, line 20) that describes that in 
step 59, a fast path candidate packet (i.e. packet header identified as TCP/IP or 
SPX/IPX) is identified by the CPD. Next, Boucher discloses that in step 53, an 
initial fast path candidate packet's CCB is not matched to the CCB cache, such 
as in a new network traffic connection, where a CCB message has not been 
created to be stored in the CCB cache; the fast path packet in step 65, is routed 
to a host stack for slow path processing, just as is done with a slow path 
packet . In step 51 , a CCB for the fast path candidate packet is created. In step 
67, the created CCB for the fast path candidate packet is stored in the CCB 
cache in the CPD or INIC. The CCB information in the CCB cache will be used 
to match the CCB of the subsequent fast path candidate packets for fast 
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path processing . In other words, Boucher discloses that at the beginning of a 
new network traffic connection, the fast path packet and the slow path 
packet are both routed and processed the same way, i.e., via the host 
protocol stack for slow path processing . The Examiner is referred to 
Boucher's Figs. 4A to 4C and related description (Boucher col. 7, line 20 to col. 
8, line 12) for further detail and description of the initial network traffic connection. 

Therefore, even assuming for the sake of argument that the packets' 
network traffic type is identified by the route the packet is processed, Boucher 
discloses that both the fast path candidate packet (the alleged first network traffic 
type packet) and the slow path packet (the alleged second network traffic type 
packet) are processed through the slow path at the start of a new traffic network 
connection. Therefore, the Applicant maintains that the fast path packet and 
the slow path packet are of the same network traffic type based on the 
common processing route according to the Examiner's assertion . 

Moreover, the Examiner is referred to Boucher in Fig. 4D and related 
description (col.8, lines 13-30), where Boucher discloses, that after the network 
traffic has been established (i.e., after the CCB has already been created by an 
initial fast path packet and stored in the CCB cache), a subsequent fast path 
packet is routed to be processed through the host protocol stack slow path 
processing route. Boucher discloses that in a situation where a CCB error 
occurs, or if the CPD processor cannot handle the fast path packet, the fast path 
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packet will be processed through the slow path host protocol stack until another 
CCB is created to correct the error in the CCB cache. 

Based on the above, Boucher's disclosure of both the initial network traffic 
connection and after the network traffic connection has been established, 
Boucher discloses that the fast path packet can always be processed by the slow 
path route, in addition to the alternate fast path route. In other words, the 
choice of the fast path route for the fast path packet is purely a 
performance choice, and not because the fast path packet is a different 
network traffic type, as asserted by the Examiner. 

Therefore, the Examiner's rationale that packets belonging to different 
network traffic types (i.e., the fast path packet is different than the slow path 
packet in network traffic type) are processed by different routes (i.e. fast path 
packets only take the fast path route, the slow path packet only take slow path 
route) cannot support an allegation that the fast path packet is of a different 
network traffic type than that of the slow path packet, since Boucher discloses 
that the fast path packets can always take the slow path route, both at the initial 
network connection establishment, and after the network traffic connection is 
established. 

Based on at least the foregoing rationale, the Applicant maintains that 
Boucher's fast path packet and the slow path packet are of the same network 
traffic type. Accordingly, the Applicant maintains that Boucher does not disclose 
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or suggest at least "a processor operable to process a plurality of different types 
of network traffic," as recited by the Applicant in claim 1 . 

Furthermore, the Examiner in page 3 of the Office Action argues that 
Boucher discloses in Fig. 6 two protocols, namely TCP/IP and SPX/IPX, which 
are identified in the fast path packet headers. The Examiner alleges that TCP/IP 
and SPX/IPX are two different network traffic types, being supported by the 
hardware processor in Boucher's [NIC. 

The Applicant respectfully disagrees, and refers the Examiner to Boucher 
at col. 6, lines 12-21, where Boucher discloses that SPX/IPX (Sequential 
Exchange Protocol (SPX) or Netware Core Protocol over Internetwork Packet 
Exchange (IPX)) work in a similar fashion as TCP/IP . Boucher in the 
Examiner's citation discloses that a connection needs to be established for the 
fast path packets transaction or processing. In other words, Boucher discloses 
that both TCP/IP and SPX/IPX are protocols that initiate packet transaction 
requests based on a connection establishment between a source and a 
destination, since TCP/IP and SPX/IPX are functionally similar network 
protocol types , i.e., fast path packets with headers identifying as either TCP/IP 
or SPX/IPX are processed the same way by the CPD or the INIC hardware logic. 
In fact, the Examiner is further referred to Boucher in col. 6 lines 42-43, where 
Boucher clearly teaches that the packets are identified as fast path candidates if 
"the header has header bytes denoting particular protocols, such as TCP/IP or 
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SPX/IPX, for example ". In other words, the CPD or INIC would process the 
fast path packets with headers denoting in either TCP/IP or SPX/IPX in the 
same fashion, not differently . Therefore, the Applicant maintains that Boucher 
does not disclose that TCP/IP and SPX/IPX are different network traffic 
types, as alleged by the Examiner. 

Therefore, based on the above rationale, the Applicant maintains that 
Boucher does not anticipate the limitation "the processor operable to process a 
plurality of different types of network traffic," as recited by the Applicant in claim 
1, and thus claim 1 is allowable. Likewise, independent claim 18 is similar in 
many respects to claim 1 , and therefore is also submitted to be allowable. The 
Applicant respectfully requests that the rejection of independent claims 1 and 18 
under 35 U.S.C. § 102(e) be withdrawn. 

Furthermore, the Applicant reserves the right to argue additional reasons 
beyond those set forth herein to support the allowability of the independent 
claims 1 and 18 should such a need arise. 

A(2) Dependent Claims 2-4, 15-20 and 23 

Based on at least the foregoing, the Applicant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by 
Boucher has been overcome and should be withdrawn. The Applicant submits 
that claims 2-4, 15-20 and 23 depend directly or indirectly from the independent 
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claims 1 and 18, and are, consequently, also respectfully submitted to be 
allowable, and requests that the rejection under 35 U.S.C. § 102(e) be 
withdrawn. 

In addition, regarding claim 3, the Applicant has reviewed the Examiner's 
citation in Boucher's abstract, col. 3, lines 35-67, and col. 13, lines 24-35, and 
points out that Boucher discloses only one type of Ethernet traffic, i.e. the offload 
traffic by fast path (via the I NIC processor and DMA controller) or slow path (via 
the host protocol stack). Boucher does not disclose other network traffic types, 
namely, the storage traffic, IPC, management traffic and RDMA traffic, as 
asserted by the Examiner. Claim 3 is submitted to be allowable based at least 
on this rationale. Claim 19 is allowable for at least the same rationale as 
discussed with respect to claim 3. 

In addition, regarding claim 15, the Applicant refers the Examiner to the 
same argument set forth above with respect to claim 1 , that the fast path and the 
slow path traffic are not different network traffic types. Claim 15 is submitted to 
be allowable based at least on this rationale. Claims 17 and 23 is allowable for 
the same rationale discussed with respect to claim 1 and 18 respectively. 

The Applicant reserves the right to argue additional reasons beyond those 
set forth herein to support the allowability of dependent claims 2-4, 15-20 and 23 
should such a need arise. 
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V. REJECTION UNDER 35 U.S.C. § 103 

In order for a prima facie case of obviousness to be established, the 
Manual of Patent Examining Procedure, Rev. 6, Sep. 2007 ("MPEP") states 
the following: 

The key to supporting any rejection under 35 U.S.C. 
103 is the clear articulation of the reason(s) why the 
claimed invention would have been obvious. The 
Supreme Court in KSR International Co. v. Teleflex 
Inc., 82 USPQ2d 1385, 1396 (2007) noted that the 
analysis supporting a rejection under 35 U.S.C. 103 
should be made explicit. The Federal Circuit has 
stated that "rejections on obviousness cannot be 
sustained with mere conclusory statements; instead, 
there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion 
of obviousness." 

See the MPEP at § 2142, citing In re Kahn, 441 F.3d 977, 988, 78 
USPQ2d 1329, 1336 (Fed. Cir. 2006), and KSR International Co. v. 
Teleflex Inc., 82 USPQ2d at 1396 (quoting Federal Circuit statement with 
approval). Further, MPEP § 2143.01 states that "the mere fact that 
references can be combined or modified does not render the resultant 
combination obvious unless the results would have been predictable to 
one of ordinary skill in the art" (citing KSR International Co. v. Teleflex 
Inc., 82 USPQ2d 1385, 1396 (2007)). Additionally, if a prima facie case of 
obviousness is not established, the Applicant is under no obligation to 
submit evidence of nonobviousness: 
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The examiner bears the initial burden of factually 
supporting any prima facie conclusion of 
obviousness. If the examiner does not produce a 
prima facie case, the applicant is under no obligation 
to submit evidence of nonobviousness. 

See MPEPat§2142. 

A. The Proposed Combination of Boucher and Kistler, Does Not Render 
Claims 10 and 11 Unpatentable 

Claims 10 and 11 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of 

Kistler et al. (US Publication No. 2002/0198934, hereinafter "Kistler"). 

Based on at least the foregoing, the Applicant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by 
Boucher has been overcome and should be withdrawn. Kistler does not 
overcome Boucher's deficiency in disclosing the Applicant's limitation. The 
Applicant submits that claims 10-11 depend directly or indirectly from the 
independent claim 1, and are, consequently, also respectfully submitted to be 
allowable, and requests that the rejection under 35 U.S.C. § 103(a) be 
withdrawn. 
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B. The Proposed Combination of Boucher and Microsoft, Does Not 
Render Claims 12 - 14 Unpatentable 

Claims 12-14 are rejected under 35 USC 103(a) as being unpatentable 

over Boucher, as applied to claim 1 above, and further in view of Microsoft 

(Winsock Direct and Protocol Offload on SANs, 03/03/2001, hereinafter 

"Microsoft"). 

Based on at least the foregoing, the Applicant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by 
Boucher has been overcome and should be withdrawn. Microsoft does not 
overcome Boucher's deficiency in disclosing the Applicant's limitation. In 
addition, the Applicant submits that claims 12-14 depend directly or indirectly 
from the independent claim 1 , and are, consequently, also respectfully submitted 
to be allowable, and requests that the rejection under 35 U.S.C. § 103(a) be 
withdrawn. 

C. The Rejection of Claim 21 Under Office Notice 

Claim 21 is rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 18 above, and further in view of Official Notice, 
hereinafter "ON"). The Applicant points out that the Examiner has cited Microsoft 
Computer Dictionary (fifth edition) to show TDM to transmit segments of one 
signal or traffic , which does not read on the Applicant's claimed limitation of 
"employing time division multiplexing to determine which of the different 
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types of network traffic access the software services via the single data 
path ". The Applicant submits that claim 21 is allowable. 

In addition, based on at least the foregoing, the Applicant believes the 
rejection of the independent claims 1 and 18 under 35 U.S.C. § 102(e) as being 
anticipated by Boucher has been overcome and should be withdrawn. The 
Applicant submits that claim 21 depends directly or indirectly from independent 
claim 18, and is, consequently, also respectfully submitted to be allowable, and 
requests that the rejection under 35 U.S.C. § 103(a) be withdrawn. 

D. The Proposed Combination of Boucher and Yang Does Not Render 
Claim 22 Unpatentable 

Claim 22 is rejected under 35 USC 103(a) as being unpatentable over 

Boucher, as applied to claim 18 above, and further in view of Yang et al. (US 

Publication No. 2002/0041566, hereinafter "Yang"). 

Based on at least the foregoing, the Applicant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by 
Boucher has been overcome and should be withdrawn. Yang does not 
overcome Boucher's deficiency in disclosing the Applicant's limitation. In 
addition, The Applicant submits that claim 22 depends directly or indirectly from 
independent claim 18, and is, consequently, also respectfully submitted to be 
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allowable, and requests that the rejection under 35 U.S.C. § 103(a) be 
withdrawn. 

E. The Proposed Combination of Boucher and Hayes Does Not Render 
Claims 5-8 and 24-28 Unpatentable 

Claims 5-8 and 24-28 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of 

Hayes et al (US Publication No. 2003/0046330, hereinafter "Hayes"). 

Regarding the rejection of independent claim 24, the Applicant submits 
that the same rationale supporting the allowability of claim 1 is applicable, that 
the fast path and slow path packets handled by Boucher's MAC 402 are not 
different network traffic types. Hayes does not overcome Boucher's deficiency in 
disclosing the Applicant's limitation. Based on at least the foregoing, the 
Applicant believes the rejection of the independent claim 24 under 35 U.S.C. § 
103(a) as being anticipated by Boucher in view of Hayes has been overcome and 
should be withdrawn. In addition, the Applicant submits that claims 5-8 and 25- 
28 depend directly or indirectly from the independent claims 1 and 24, and are, 
consequently, also respectfully submitted to be allowable, and requests that the 
rejection under 35 U.S.C. § 103(a) be withdrawn. 
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F. The Proposed Combination of Boucher and Callaghan Does Not 
Render Claims 29-31 Unpatentable 

Claims 29-31 are rejected under 35 USC 103(a) as being unpatentable 

over Boucher, and further in view of Callaghan (NFS over RDMA, hereinafter 

"Callaghan"). 

Regarding the rejection of independent claim 29, the Applicant submits 
that the same rationale supporting the allowability of claim 1 is applicable, that 
the fast path and slow path packets handled by the PCI bridge 157 and INIC 
miniport driver 306 are not different network traffic type. Callaghan does not 
overcome Boucher's deficiency in disclosing the Applicant's limitation. Based on 
at least the foregoing, the Applicant believes the rejection of the independent 
claim 29 under 35 U.S.C. § 103(a) as being anticipated by Boucher in view of 
Callaghan has been overcome and should be withdrawn. In addition, the 
Applicant submits that claims 30-31 depend from the independent claim 29, and 
are, consequently, also respectfully submitted to be allowable, and requests that 
the rejection under 35 U.S.C. § 103(a) be withdrawn. 

Furthermore, the Applicant reserves the right to argue additional reasons 
beyond those set forth herein to support the allowability of claims 5-14, 21-22 
and 24-31 should such a need arise. 



Page 33 of 34 



Application No. 10/652,327 

Reply to Office Action of June 5, 2008 

CONCLUSION 

Based on at least the foregoing, the Applicant believes that all claims 1-31 
are in condition for allowance. If the Examiner disagrees, the Applicant 
respectfully requests a telephone interview, and requests that the Examiner 
telephone the undersigned Patent Agent at (312) 775-8093. 

The Commissioner is hereby authorized to charge any additional fees or 
credit any overpayment to the deposit account of McAndrews, Held & Malloy, Ltd., 
Account No. 13-0017. 

A Notice of Allowability is courteously solicited. 

Respectfully submitted, 



Date: July 30, 2008 / Frankie W. Wong/ 

Registration No. 61 ,832 
Patent Agent for Applicant 



McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
(312)775-8093 (FWW) 
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